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Even inexpensive modems run at 2,400 
bits per second today, and newer designs 
push the upper limit to 9,600 bps and be- 
yond. Direct serial links between ma- 
chines allow even higher transmission 
rates. 300-bps communications programs 
went out with the Hula Hoop — about the 
time the designers of DOS wrote its serial 
driver. 

There's nothing in DOS itself to pre- 
clude high-speed serial I/O, of course. It's 
just that a DOS communications program 
has to write its way around the operating 
system and supply its own communica- 
tions facilities. In this first of a two-part se- 
ries on serial communications program- 
ming, we give an overview of the DOS 
communications environment, then pre- 
sent and analyze a terminal emulation pro- 
gram with advanced input capabilities. 
Next time, we'll do the same for the more 
hospitable OS/2 communications environ- 
ment. Part 2 will culminate in the code list- 
ing for a protected-mode terminal emula- 
tor that highlights the differences between 
the two environments and permits a ma- 
chine running OS/2 to communicate with 
another running DOS. 

The communications resources that 
DOS supplies are meager at best. Only one 
serial port can be accessed at a time, and 
the DOS AUX serial device driver is slow, 
rudimentary in design, and adequate only 
for polled I/O. In a polled I/O system the 
speed must be slow enough to allow the 
CPU to spend an appreciable fraction of its 
clock cycles checking each port in turn 
("polling") to see whether a character is 
waiting to be either transmitted or re- 
ceived. This is impractical for speeds 
greater than 300 bps. 

Handling high-speed data transfers re- 
quires more-sophisticated, interrupt-driv- 
en I/O techniques. In an interrupt-driven 
system the CPU doesn't waste clock cy- 
cles looking for work. Instead, the UART 
chip that drives the serial port grabs the at- 
tention of the CPU ("interrupts") only 
when a character actually arrives. If the in- 
terrupt handler is written with sufficiently 
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low overhead, the chance of losing an in- 
coming character because the last charac- 
ter is still being processed is virtually nil. 
Similarly, in interrupt-driven output, the 
serial port notifies the CPU when another 
character can be transmitted, freeing it to 
keep up with other tasks in the interim. 

The DOS services that support serial 
I/O through the interrupt 0x2 1 interface are 
simply inadequate for interrupt-driven ap- 
plications. (Note: The Ox prefix is the C 
language method of denoting hexadecimal 
numbers, a convention we've adopted 
here.) Indeed, since DOS provides no fa- 
cilities for programs even to initialize the 
serial port to given transfer rates and line 
control settings, programmers must fall 
back either on using the ROM BIOS or 
programming the serial port hardware di- 
rectly. As we'll see, however, the BIOS 



offers only slightly better support for serial 
I/O than does DOS itself. Thus, as a practi- 
cal fact of life, DOS programmers have 
long grown accustomed to bypassing the 
operating system and firmware altogether 
to transmit and receive serial data. 

DOS COMMUNICATIONS ENVIRONMENT 

The heart of a serial port is a chip called the 
Universal Asynchronous Receiver/Trans- 
mitter, or UART. It is the UART that 
physically transmits and receives charac- 
ters through the pins of an RS-232 connec- 
tor. When a character is to be transmitted, 
the UART frames it with the proper start, 
stop, and parity bits. The UART then puts 
this data, one bit at a time, onto the TD 
(Transmit Data) pin, at predefined inter- 
vals. Likewise, when an incoming data 
packet is received on the RD (Receive 
Data) pin, the UART disassembles the 
packet and presents it in the form of an un- 
framed 7- or 8-bit character. The specific 
UART used in the IBM PC family is a Na- 
tional INS8250 Asynchronous Communi- 
cations Controller (or a workalike). It's 
more commonly referred to as "the 
8250," or simply "the UART." 

The UART also supplies a number of 
higher-level functions that help put charac- 
ter input and output under program con- 
trol. If desired, it will compare the parity 
bit of each character it receives against a 
parity value it calculates itself and report a 
parity error if the two don't agree. It will 
also report a receiver overrun error if a re- 
ceived character isn't read from the 
UART's internal buffer before the next 
one arrives, and a framing error if an in- 
correct stop bit is detected. 

Registers inside the UART hard-wired 
to the RS-232 control pins allow programs 
to perform hardware handshaking with de- 
vices connected to the serial port. Thus, 
for example, a transmitting device may as- 
sert the RTS pin, indicating that it is Ready 
to Send a character. Before actually send- 
ing the character, however, the transmit- 
ting device may require confirmation that 
the device on the other end of the line is 
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ready to receive. The UART provides this 
confirming "handshake" by asserting the 
CTS (Clear to Send) pin. 

The BIOS does provide four interrupt 
Ox 14 functions designed to permit applica- 
tions to use the serial port without requir- 
ing programmers to deal directly with the 
inner complexities of the UART. These 
functions are detailed in Figure 1 . Func- 
tion initializes the UART to the data 
transfer rate (expressed in bits per second) 
and line control settings specified by the bit 
pattern in AL. Rates up to 9,600 bps are 
supported. Function 1 transmits the char- 
acter in AL to the serial port, while func- 
tion 2 reads a character from it. Function 3 
returns a 16-bit value that represents the 
status of the serial port in AX. On return, 
AH reflects the current line status (ac- 
quired directly from the UART's Line Sta- 
tus register) and AL holds the modem sta- 
tus bits (obtained from the Modem Status 
register). 

Functions 2 and 3 use simple hardware 
handshaking schemes to make sure that 
spurious data is neither transmitted nor re- 
ceived. Function 2 asserts DTR (Data Ter- 
minal Ready) and RTS (Ready to Send) 
before outputting a character. It then waits 
for DSR (Data Set Ready) and CTS (Clear 
to Send) to be asserted in response. Func- 
tion 3 asserts DTR, then waits for DSR to 
be asserted before attempting to read a 
character. 

The vital shortcoming of these services, 
however, is that the BIOS has no way to al- 
ter the handshaking modes. The BIOS ser- 
vices are thus generally limited to use in 
two programs designed to talk to each oth- 
er, or to situations in which the device on 
the other end of the line is known to em- 
ploy the same protocol. 

Figure 2 shows how several DOS inter- 
rupt 0x2 1 services use the BIOS to provide 
simple input and output services. Function 
3 of interrupt 0x21 waits for a character to 
appear at the serial port and returns it in 
AL. Function 4 transmits the character in 
DL. The primary difference between the 
DOS and BIOS character transmit and re- 
ceive services is that the BIOS routines 
will return to the caller with bit 7 of AH set 
if a time-out counter expires before a char- 
acter can be transmitted or read. The DOS 
functions, by contrast, will hang in an end- 
less loop. You can prevent such hangups 
by checking the status of the UART before 




Call with: AH -- 

AL = Communications parameters (see belo 

DX = Serial port number (0-3) 
Returns: AH = Line status (see function 3 below) 

AL = Modem status (see function 3 below) 

Bit 7 is set in AH if function timed-out 
Bit settings in the communications parameters byte: 



Bits 7, 6, 5 

000 
001 
010 
011 
100 
101 
110 

111 



Data rate 

110 bps 
1 50 bps 
300 bps 
600 bps 
1 ,200 bps 
2,400 bps 
4,800 bps 
9,600 bps 



Bits 4, 3 

X0 
01 

11 

Bit 2 


1 

Bits 1,0 

10 
11 



Parity setting 

No parity 
Odd 
Even 

Number of stop bits 

1 bit 

2 bits 

Number of data bits 

7 bits 

8 bits 



Function 1 

Call with: 



Returns: 

Function 2 

Call with: 

Returns: 



Function 3 

Call with: 

Returns: 



Output Character 

AH = 1 

AL = Character code 
DX = Serial port number (0-3) 
AH = Line status (see function 3 below) 
Bit 7 is set in AH if function timed-out 
Input Character 
AH = 2 

DX = Serial port number (0-3) 
AH = Line status (see function 3 below) 
AL = Character code 
Bit 7 is set in AH if function timed-out 
Get Serial Port Status 
AH = 3 

DX = Serial port number (0-3) 

AH = Line Status AL 

Bit 7 = Undefined Bit 

Bit 6 = Transmit Holding 

and Transmit Shift Bit 
registers empty Bit 

Bit 5 = Transmit Holding 

register empty gj t 

Bit 4 = BREAK detected Bit 

Bit 3 = Framing error g| t 

Bit 2 = Parity error Bjt 

Bit 1 = Overrun error gj t 

Bit = Data ready in Receive 
Buffer register 



: Modem Status 

= DCD (Data Carrier Detect) 

asserted 
■■ Rl (Ring Indicator) asserted 

. DSR (Data Set Ready) 
asserted 

■■ CTS (Clear to Send) asserted 
: Delta DCD 
: Delta Rl 
: Delta DSR 
. Delta CTS 




Figure 1 : The BIOS interrupt 0x1 4 does provide programmers with a set of functions for creating 
applications that can access the serial port, without requiring them do deal directly with the inner 
complexities of the UART. However, these services lack the flexibility needed to support a variety of 
handshaking methods and are, therefore, generally limited. 
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calling function 3 or 4. The only way to do 
this without bypassing the operating sys- 
tem altogether, however, is by making a 
separate call to IOCTL, which is a highly 
inefficient procedure. 

There are, as indicated, additional 
problems about DOS's serial I/O support. 
For one, the only means DOS provides to 
initialize a serial port or point the AUX 
driver to a device other than COM 1 is by 
execution of a MODE command from the 
command line. Worse, like the BIOS ser- 
vices, the DOS services are inherently 
suited for polled I/O only; interrupt-driven 
operation requires special programming. 

FACING THE INEVITABLE 

Thus, when running under DOS, neither 
its services nor the BIOS's are adequate for 
high-speed serial communications. The 
functionality needed for interrupt-driven 
I/O is available only by dispensing with the 
operating system's aid and working direct- 
ly at the UART level. 

The UART is programmed to generate 
an interrupt when an I/O-related event oc- 
curs, and the 8259 Programmable Inter- 
rupt Controller is programmed to pass the 
interrupt on to the CPU. By setting select- 
ed bits in its Interrupt Enable register, the 
UART can be made to generate an inter- 
rupt under a wide variety of conditions: 
when a byte is received in its Receive Buff- 
er register; when its Transmit Holding reg- 
ister is ready to accept another character; 
when a parity, overrun, or framing error 
occurs; when a BREAK is detected; or 
when the state of an RS-232 input pin 
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Function 3: Input Character 

Call with: AH = 3 

Returns: AL = Character code 

Function 4: Output Character 

AH = 4 

DL = Character code 




Figure 2: The rudimentary serial I/O services 
that DOS interrupt 0x21 supplies do not include 
any way of initializing ports and will hang if a 
time-out error is encountered. 



changes. The application program sets up 
interrupt handlers to service each interrupt 
it has chosen to recognize. If more than 
one type of interrupt is enabled, the pro- 
gram can determine which condition trig- 
gered the most recent one by reading the 
UART's Interrupt Identification register. 

A layout of the UART registers is 
shown in Figure 3. Within the PC, a table 
containing the 16-bit I/O addresses of all 
UARTs installed in the system is stored at 
offset in the BIOS data area. Once a 
UART's base address is obtained, its inter- 
nal registers are accessed relative to that 
base. An address of indicates that the 
corresponding serial port is not installed. 
Figure 4 shows how the UART generates 
and identifies interrupts. 

In addition to the Interrupt Enable and 
Interrupt Identification registers, the Re- 
ceive Buffer/Transmit Holding, Line Con- 
trol, and Modem Control registers also 
play an important role in interrupt-driven 
serial communications. The Receive Buf- 
fer/Transmit Holding register performs 
double-duty: a byte written to it with an 
OUT instruction is transferred to the 
UART's Transmit Shift register and out- 
put; a byte read from it with an IN is pulled 
from the UART's Receive Buffer register. 

The Line Control register contains data 
format information, which defines the 
number of data bits, the number of stop 
bits, and the parity setting. In addition, bit 
7 of this register serves as the Divisor 
Latch Access Bit, or DLAB . When DLAB 
is zero, the ports at offsets and 1 from the 
base address correspond to the UART's 
Receive Buffer/Transmit Holding and In- 
terrupt Enable registers, respectively; 
when DLAB is 1 , the same I/O addresses 
are mapped to the Baud Rate Divisor regis- 
ters. An interrupt service routine that reads 
the serial port must thus take care to clear 
DLAB before reading a character with an 
IN from the address at offset 0. Otherwise, 
the character returned may actually have 
come from the LSB (Least-Significant- 
Bit) Baud Rate Divisor register. 

Finally, the Modem Status register con- 
tains the DTR (Data Terminal Ready) and 
RTS (Request to Send) control bits. It also 
contains the general-purpose GP02 output 
bit. In the IBM implementation, this bit 
must be set before UART interrupts can 
reach the CPU. Bits that correspond to the 
RS-232 input pins DSR (Data Set Ready), 
CTS (Clear to Send), RI (Ring Indicator), 
and DCD (Data Carrier Detect), when 
needed, are found in the Modem Status 
register. 



THE DOS COMMUNICATIONS MODEL 

The core of a DOS communications pro- 
gram is the set of interrupt service routines 
(ISRs) that processes UART interrupts. 
This module may either be incorporated 
within the program itself, or it may take the 
form of an installable device driver that is 
loaded from the CONFIG.SYS file. Most 
software writers choose the former alterna- 
tive, reasoning that an application program 
should be written so that its operation is in- 
dependent of external resources. More- 
over, an I/O module contained in an .EXE 
file is erased when the program terminates. 



The number and 
sophistication of 
interrupt service 
routines that are 
written depends upon 
the nature of the 
communications 
services needed. 



A device driver, on the other hand, re- 
mains in memory until the system is re- 
started. This wastes RAM that could be 
used by subsequently loaded application 
programs. 

The number and relative sophistication 
of interrupt service routines to be written 
depends upon the nature of the communi- 
cations services needed. A simple applica- 
tion, such as the terminal emulator pre- 
sented here, will have at least one ISR to 
intercept interrupts triggered when a char- 
acter is received by the UART. The ISR 
reads incoming characters and buffers 
them in a circular first-in, first-out (FIFO) 
queue. 

The balance of the program — the por- 
tion that processes input — reads from the 
queue rather than from the UART. The 
procedure is identical to the way the BIOS 
buffers keystrokes in the keyboard buffer 
and makes them available through inter- 
rupt 0x16. 

As long as the queue isn't filled, the pri- 
mary program routines are freed from the 
time constraints that are normally associat- 
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the most exciting graphics package in the 
industry - with ease of use, versatility and 
speed that exceeds even Macintosh programs! 
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ed with high-speed asynchronous I/O pro- 
cessing. And since the ISR is responsible 
only for reading and buffering incoming 
data, unless the transfer rate is extremely 
high the likelihood that it will miss a char- 
acter is slight. 

More sophisticated ISRs shoulder addi- 
tional burdens. If high-speed data output is 
required, an application can effect inter- 
rupt-driven output by setting up a separate 
ISR to service the UART interrupts that are 
generated as the Transmit Holding register 
is emptied. 

Output will be directed to a holding 
buffer and it will then be spooled to the 
UART, a character at a time, by the ISR. 
Additional ISRs can also handle errors re- 
ported by the UART, if desired. 

A properly written communications 
program running under DOS can achieve 
data transfer rates beyond 9,600 bps even 
on a 4.77-MHz PC, as is proved by some 
of the commercial utilities that have been 
designed to transfer data between laptop 
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THE UART REGISTERS 



Address 

+0: 

+1: 
+2: 
+3: 
+4: 
+5: 
+6: 
+0: 
+1: 



'Mapped into this address when DLAB = 1 . 
DLAB is the Divisor Latch Access Bit, which is 
bit 7 of the Line Control register. When DLAB 
is 0, the Receive Buffer/Transmit Holding 
register is accessed at offset and Interrupt 
Enable at offset 1 . When DLAB is 1 , the same 
I/O addresses correspond to the Baud Rate 
Divisor Latch registers. 



Receive Buffer/ 
Transmit Holding 

Interrupt Enable 

Interrupt Identification 

Line Control 

Modem Control 

Line Status 

Modem Status 

LSB Baud Rate Divisor* 

MSB Baud Rate Divisor* 



Figure 3: To access and program an internal 
register of the UART, you must first obtain the 
correct base address from the table stored in the 
BIOS data area. To write to the internal registers 
sted above, you then add the corresponding 
jffset values to the base address. The range of 
services that each UART register provides is 
detailed in Figure 4. 



PCs and desktop models over specially 
built cables. Faster machines can handle 
even higher rates. 

Note, however, that at high transfer 
rates approaching the threshold of a given 
PC's capabilities, programs must usually 
be optimized for speed at the expense of 
handshaking and parity checking. Under 
these circumstances, file-transfer proto- 
cols with fixed packet sizes are used to 
make sure that transmission errors are de- 
tected and corrected. 



IMPLEMENTING THE MODEL 

The schematic representation of a commu- 
nications program that carries its own in- 
terrupt-driven serial input logic on-board is 
shown in Figure 5. Incoming data is re- 
ceived and buffered by an ISR and the pro- 
gram, as described above, reads data from 
the input queue. In the typical fashion of a 
terminal emulator, in which the output rate 
is no greater than the speed of the typist, 
outgoing data is delivered directly to the 
UART. Note that the operating system and 
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Interrupt Enable Register: 



Bit 7 = Always 
Bit 6 = Always 
Bit 5 = Always 
Bit 4 = Always 

Interrupt Identification Register: 



Bits 3, 2, 
001 
110 
100 



Bits 5, 4, 3 
000 
001 
011 
101 
111 



Interrupt source 
No interrupt 

Error or BREAK detected 

Data ready in Receive 
Buffer register 

Line Control Register: 

Bit 7 = Divisor Latch Access Bit 
Bit 6 = BREAK control 

Off 

1 On 

Parity setting 
No parity 
Odd 
Even 
Mark 
Space 

Modem Control Register: 

Bit 7 = Always 
Bit 6 = Always 
Bit 5 = Always 
Bit 4 = Loopback test 
Line Status Register: 
Bit 7 = Always 

Bit 6 = Transmit Holding and Transmit 
Shift registers empty 

Bit 5 = Transmit Holding register empty 

Bit 4 = BREAK detected 

Modem Status Register: 

Bit 7 = DCD asserted 
Bit 6 = Rl asserted 
Bit 5 = DSR asserted 
Bit 4 = CTS asserted 



Bit 3 = Change in RS-232 input pin 

Bit 2 = Error or BREAK detected 

Bit 1 = Transmit Holding register empty 

Bit = Data ready in Receive Buffer register 

010 Transmit Holding 
register empty 

000 Change in RS-232 input pin 



Bit 2 Number of stop bits 

1 bit 

1 2 bits 

Bits 1 , Number of data bits 

00 5 bits 

01 6 bits 

10 7 bits 

1 1 8 bits 



Bit 3 = GP02 
Bit 2 = GP03 
Bit 1 = RTS 
Bit = DTR 

Bit 3 = Framing error 
Bit 2 = Parity error 
Bit 1 = Overrun error 
Bit = Data ready in Receive 
Buffer register 

Bit 3 = Delta DCD 
Bit 2 = Delta R! 
Bit 1 = Delta DSR 
Bit = 




Figure 4: By programming the UART directly, the full range of services needed for interrupt-driven 
serial communications is made available. 
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BIOS are merely spectators; all interaction 
takes place between the communications 
program and the serial port hardware. 

This schema is implemented in DOS- 
TERM, a simple but fully functional ter- 
minal emulation program that permits 
characters typed at one PC to appear on the 
screen of another. The COM1 ports of the 
two PCs should be tied together by a null 
modem cable — that is, a cable in which the 
TD and RD lines are cross-wired so that 
what is transmitted on TD at one end pre- 
sents itself on RD at the other end. 

The assembly language listing for 
DOSTERM is shown in Figure 6. The pro- 
gram is designed to be assembled and 
linked into a standalone .EXE file. Fol- 
lowing the conceptual model diagrammed 
in Figure 5, DOSTERM sets aside a 
1,024-byte internal buffer for incoming 
characters and provides an ISR — labeled 
READ_COM in the source code — to ser- 
vice them. It displays incoming data on the 
screen, echoes any characters typed at its 
own keyboard to the screen before trans- 
mitting them out COM1, and terminates 
when the Esc key is pressed. 

In the interest of simplicity, DOS- 
TERM performs no handshaking with the 
external device to which it is linked. (It 
does, however, assert DTR and RTS, just 
in case the device at the other end relies on 
these pins.) Nor does it offer any means of 
flow control — a subject that will be treated 
in more detail in next issue's discussion of 
OS/2 communications programming. 

At startup, DOSTERM initializes the 
UART and the 8259A for interrupt-driven 
operation. The appropriate software inter- 
rupt— OxOC for COM1 (OxOB would 
have been used had the program been writ- 
ten for COM2) — is altered to point to an 
ISR that provides low-level communica- 
tions services. The ISR is complemented 
by two routines, READ_CHAR and 
SEND_CHAR, that act as an interface to 
the rest of the program. It calls these rou- 
tines as needed to read and write characters 
to and from the serial port, completely 
oblivious to the fact that incoming charac- 
ters are being buffered in the background 
by another component of the same pro- 
gram. Just before the program terminates, 
it deprograms the UART and 8259A and 
restores the interrupt vector that was dis- 
placed at runtime. After performing nor- 
mal housekeeping chores, it ends, leaving 
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Proper execution of the hardware ini- 
tialization sequence is critically important. 
To set up its host for interrupt-driven I/O, 
DOSTERM performs the following steps: 

■ Obtains the base address of the COM1 
UART from the BIOS data area; 

■ Changes the interrupt OxOC vector to 
route UART interrupts to the interrupt ser- 
vice routine READ_COM; 

■ Initializes the UART to 9,600 bps, no 
parity, 8 data bits, and 1 stop bit, using the 
BIOS interrupt 0x14, function (the serial 
port setup service); 

■ Unmasks IRQ4 interrupts (correspond- 
ing to COM1) by clearing bit 4 of the 
8259A's interrupt mask register at I/O ad- 
dress 0x21; 

■ Sets bit of the UART's Interrupt En- 
able register so that an interrupt will be 
generated whenever a character is received 
byCOMl; 

■ Asserts bit 3 of the UART's Modem 
Control register so interrupts can reach the 
CPU. At the same time, bits and 1 are 
set, enabling DTR and RTS, which signi- 
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the BIOS to initialize the UART to the de- 
sired data transfer rate and line settings. As 
an alternative, it could have written the 
values directly to the Line Control and Di- 
visor Baud Rate registers. 

Interrupts generated by COM1 and 
COM2 are tied to the PC's dedicated IRQ4 
and IRQ3 hardware interrupt lines, respec- 
tively. These, in rum, are associated with 
software interrupts OxOC and OxOB. The 
first step in setting up an ISR to service 
UART interrupts is to point the appropriate 
interrupt vector to it. In DOSTERM, 
which uses COM1 exclusively, this inter- 
rupt is OxOC. The original value of the vec- 
tor is saved before modification so that it 
can be restored upon termination. 

No hardware interrupt can reach the 
CPU until the corresponding bit in the 
8259A's interrupt mask register is set to 0. 
Bits 3 and 4 are assigned to IRQ3 and 
IRQ4, respectively, and the default setting 
of both bits is 1 . This disables both the 
IRQ 3 and IRQ4 interrupts unless a pro- 
gram takes explicit action to enable them. 




Serial 
input 
queue 



DOS 




Figure 5: When a DOS communications program requires interrupt-driven input, both the operating 
system and BIOS must be bypassed and the UART programmed directly. In this model, an ISR 
handles interrupts triggered by the UART when a character is waiting to be read. The character is 
buffered in a circular queue from which the program can retrieve it when time permits. Outgoing 
characters are sent directly to the UARTs Transmit Holding register, a technique typical in a terminal 
emulator whose data transmission rates are low. 
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DOSTERM enables COM1 interrupts but 
leaves COM2 interrupts masked off. It 
then follows up by asserting GP02 (bit 3) 
in the UART's Modem Control register. 
GP02 controls a hardware gateway in the 
PC that, when closed, cuts off UART in- 
terrupts before they reach the 8259A. 

At this point, the ISR is being properly 
addressed by an interrupt vector, and the 
path from the UART hardware to the CPU 
is clear. It then remains only to activate 
UART interrupts by setting bit of its In- 
terrupt Enable register. By default, all bits 
in this register are clear. With bit set, in- 
terrupts are triggered when characters are 
delivered to the Receive Buffer register, a 
sign that data is waiting to be read. Other 
bits control other interrupt options. Had 
DOSTERM been endowed with interrupt- 
driven output capabilities, it would have 
also set bit 1 so that it would be notified 
when the Transmit Holding register could 
accept another character for output. 

Adding interrupt-driven output would 
have introduced one further complication, 
however. Since only one interrupt vector is 
assigned to each serial port, if two ISRs are 
needed to service it (one for data-ready in- 
terrupts, another for Transmit Holding 
register-ready interrupts), both ISRs 



would have to be combined into a single 
ISR package. A dispatcher at the front end 
of the package would be required to deter- 
mine which condition triggered the inter- 
rupt and to route execution to the input or 
the output ISR appropriately. 

The key to performing such electronic 
gymnastics is the UART's Interrupt Identi- 
fication register. When interrupts are mul- 
tiplexed, the lower 3 bits of the Interrupt 
Identification register identify the source 
of the last interrupt. A Data Ready condi- 
tion, for example, is characterized by the 
value 4. A value of 2 identifies a Transmit 
Holding register-ready interrupt. Other in- 
terrupt ID values are shown in the section 
of Figure 4 that maps the Interrupt Identifi- 
cation register. 

READ_COM reads the serial port and 
puts each successive character into a 
1,024-byte FIFO queue named 
DATAJBUFFER. Two pointers into the 
buffer— BUFFER_HE AD and BUF- 
FER_TAIL — designate where the next 
character will be written to and extracted 
from, respectively. 

Incoming characters are copied into the 
location indexed by BUFFERJHEAD. 
After a character is inserted, BUF- 
FERJHEAD is advanced so that the next 
character will not overwrite the last. When 
a character is read from the buffer, it is re- 
trieved from the address held in BUF- 
FER_TAIL, and BUFFERJTAIL is in 



turn incremented to the next position. 
Thus, when the head and tail addresses are 
equal, the buffer is empty, and when the 
next increment of the head would allow it 
to overtake the tail, the buffer is full. If a 
new character is received with the buffer 
full, it is ignored. The next one will be duly 
buffered provided that a slot has opened 
for it in the queue. 

To ensure that it gets top priority when 
an interrupt is received, READ_COM 
leaves interrupts disabled while it runs. 
Before it ends, it sends an end-of-interrupt 
command to the 8259A to signal that pro- 
cessing is completed. Until this occurs, 
hardware interrupts of equal and lower pri- 
ority are withheld from the CPU. 

READ_COM operates asynchronously 
from the main body of the program, which 
is contained in the procedure TERM. 
TERM executes a simple loop, alternately 
polling the keyboard and serial input buff- 
ers for data. When a keycode appears in 
the keyboard buffer, it is read, displayed, 
and transmitted; when a character appears 
in the serial input queue, it is read and dis- 
played. The queue is checked for new 
characters simply by comparing the head 
and tail addresses. If the addresses are the 
same, no data is waiting to be read. 

Characters are read from the queue with 
the subroutine READ_CHAR. To ensure 
that it isn't interrupted by READ_COM 
while in the midst of extracting a character 



DOSTERM.EXE 



; DOSTERM. ASM - A DOS terminal emulation program 

; This code illustrates how a program written for the Dos 

; environment can program the UART and interrupt controller 

; for interrupt-driven serial I/O. An ISR is set up to 

; service received data ready interrupts coming from IRQ4 <COMl) 

; and buffer the data in a 1,024-byte circular queue similar to 

; the Bios keyboard buffer. 

; Characters are read from the queue by calling the subroutine 

; READ_CHAR. Characters transmitted are output directly to the 

; UART by SEND_CHAR. Execution ends when the Esc key is pressed. 

; Copyright (c> 1989 ziff Communications Company 



INTA00 
INTA0 1 

data 

error_mag 
data_buf fer 
buf fer_start 
buf fer_end 
buf fer_head 
buffer^tail 
uart_addr 
int«Ch 
data 

stack 

stack 

code 



egu 
equ 



20h 
21h 



;8259A IRQ control register 
;8259A IRQ mask register 



segment word public 'DATA' 



db 
db 
dw 
dw 
dw 
dw 
dw 
dd 
ends 



-COMl not installed", 13, 18, "5" 

1B24 dup (?) ;input buffer 

offset data buffer ; starting buffer address 

offset buffer_start ,-ending buffer address 

offset data_buffer jlocation for next write 

offset data_buffer jlocation for next read 

? ; uart base address 

? ;old interrupt 0Ch vector 



segment stack 

dw 256 dup (?) 

ends 



; stack area 



segment word public * CODE * 
assume cb : code , ds idata, as ; stack 



calls TERM to perform terminal emulation functions. 



proc 

mov 

roov 



far 

ax ( data 



; point DS to the data 
; segment 



; obtain the base address of COHl from the Bios data area. 



mov 


ax, 40h 


j point ES to data area 


mov 


es,ax 




mov 


ax, word ptr ea! 


[8] ;get the word at 0040:0000b 


mov 


uart_addr,ax 


;save it 


or 


ax, ax 


;exit on error if COHl 


jnz 


vector 


; is not installed 


mov 


ah, 9 




mov 


dx, offset error 


mag 


int 


21h 




mov 


ax,4c81h 




int 


21h 





;Save the old interrupt 0Ch vector and point it to reao_coh . 

vector: mov ax,35«Ch ;obtain and save the current 

int 21h ; value of the int 0ch 

mov word ptr int0Ch,bx ; vector 

mov word ptr intflch [ 2 ] , ea 

assume ds:nothing ; save DS 

push ds 

mov ax,cs 

mov ds, ax 

mov ax,258ch ;revector to our own 

mov dx, offset read com ; interrupt handler 

int 21h 



Figure 6: The assembly language listing for DOSTERM.EXE, a simple interrupt-driven terminal emulation program that allows characters typed on one 
PC to be sent, via a null modem cable, to the screen of a second PC. DOSTERM performs no handshaking with the external device to which it is linked. 
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Monet,not money 





The HP 
PaintJet. 
$1395* 




Who says fine art is out of reach? 
The HP PaintJet color printer pro- 
duces brilliant color for a price any 
business can afford. 

So now there's no limit to what 
you can create , 




with your business communica- 
tions. Surprise your audience with 
thousands of colors. Beamed up 
on an overhead. Or tucked neatly 
into a report. Persuading people 
up to 85% more effectively than 
black and white. 

The PaintJet works with all your 
favorite graphics, presentation, 
spreadsheet and word processing 
software. Just hook it up to your 
IBM-compatible or Macintosh 
computer and start painting. 



For only $1395 (add $125 for the 
Macintosh interface). 

Call 1-800-752-0900 Ext. 711K 
for your nearest authorized HP 
dealer and a free sample output. 
The HP PaintJet. It's what artists 
are starving for. 

There is a better way. 



HEWLETT 
PACKARD 



•Suggested U.S. list price. 



Business graphics created using Microsoft* Excel, which is a U. S. registered trademark of Microsoft Corp. ©1989 Hewlett-Packard Company PE 12916 
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Lab Notes 



DOSTERM.EXE 



al 



assume ds : data 

; initialize the uakt to 9609 n81. 

mov ax,00E3h 

xor dx,dx 

int 14h 



;9600 bps, no parity, 
; 8 data bits, and 1 
; stop bit 



;u"nraask IRQ4 interrupts in the 8259's IRQ mask register. 



in 

and 

out 



al,INTA01 

al,0EPh 

INTABl.al 



;clear bit 4 to unmask 
; IRQ4 (COMl) interrupts 



.•Initialize the Interrupt Enable Register and assert GP02 . 

; first clear DLAB 



mov 


dx.uart addr 


add 


dx,3 


in 


al.dx 


and 


al, 07Fh 


out 


dx, al 


sub 


dx,2 


mov 


al,l 


out 


dx.al 


add 


dx,3 


mov 


al,0Bh 


out 


dx,al 



;set bit for received data 
; ready interrupts 



; assert GPo2, DTR, and RTS 



;send and receive characters until esc is pressed. 

call ten 
; Reset the system and exit. 



mov 


dx.uart addr 


add 


dx,« 


in 


al.dx 


and 


al,»F4h 


out 


dx.al 


sub 


dx,3 


xor 


al.al 


out 


dx.al 


in 


al, INTA01 


or 


al.Hh 


out 


dx.al 


nov 


ax,25«ch 


Ids 


dx. [ intsch) 


int 


21h 


mov 


ax,4CBI)h 


int 


21h 



.clear bits 0, 1, and 3 of 
; the Modem control Register 



;disable UART interrupts 



;mask off IRQ4 interrupts 
j that reach the 8259a 



; reset the int 0Ch vector 



TERM transmits characters typed at the keyboard and displays those 
received at the serial port. 



terra proc near 

,-check the keyboard buffer and process any waiting keycodes. 
term_loop : 



output : 



int 
j* 

xor 
int 
or 
j« 

jne 
ret 

push 
call 
pop 

call 



ah,l 

16b 

keys_clear 

ah, ah 

16h 

al.al 

keys_clear 

al.BlBh 

output 



display _char 



don't read the keyboard if 
nothing is waiting 



;read keycode 

; ignore extended keycodes 

;exit if ESC was pressed 

; display the character 

;output the character 



eend_char 

,-check the serial input buffer and read it if a character ie waitin 
keys_clear : mc 



cmp 



call 

jjnp 

endp 



ax,buffer_tail 
ax,buf fer_head 
term_loop 



.■loop back if the buffer is 
; empty 



,-extract character from buffer 



display char 
term_loop 



; display it 

; return to loop 



; ; READCHAR waits for 



serial input 



queue, then reads it and returns it in AL. 



read char 


proc 


near 




no char : 


mov 


bx, buffer tail 


;loop until a character 






bx, buffer head 


; appears in the serial 




je 


no char 


; input buffer 




cli 




; interrupts off 




mov 


al, [bx] 


;read a byte from the buffer 




inc 


bx 


; and advance the tail 




cmp 


bx, buffer end 


;wrap around to start of buffer 




jne 


read_exit 


; if necessary 




mov 


bx, buffer start 




read exit: 


mov 


buffer tail.bx 






sti 




; interrupts on 




ret 




; and exit 


read^cbar 


endp 






; ; DI SPLAY_C HAR writes 


the character in 


AL to the screen buffer. 


display_char 


proc 


near 






mov 


ah, 0Eh 


j BIOS TTy function 




xor 


bh.bh 






int 


10h 






ret 






display char 


endp 






; ; SEND_CHAR 


writes the 


character in AL 


to COMl . 


send char 


proc 


near 






push 


ax 


; save character code 




mov 


dx.uart addr 


; point DX to Line Status 




add 


dx, 5 




8 end loop: 


in 


al.dx 


jloop until Transmit 




test 


al,20h 


; Holding register 




jz 


send loop 


; is empty 




sub 


dx,5 


; then output the character 




pop 


ax 






out 


dx,al 






ret 






send char 


endp 







READ_COH handles interrupts generated by COMl when a byte of data 
is received. Data is read from the UART's Receive Buffer register 
and stored in a FIFO queue. 



proc 


far 




push 


ax 


;save registers 


push 


bx 




push 


dx 




push 


ds 




mov 


ax, data 


.-establish DS addressability 


mov 


da, ax 




mov 


dx.uart addr 


;make sure DLAB is clear 


add 


dx, 3 




in 


al,dx 




and 


al,07Fh 




out 


dx,al 




mov 


dx.uart addr 


;read the character 


in 


al,dx 




mov 


bx, buffer head 


jcalculate next head position 


mov 


dx.bx 


; to make sure the buffer 


inc 


dx 


; isn't full 


cmp 


dx, buffer end 




jne 


no_wrap 




mov 


dx, buffer start 




cmp 


dx, buffer tail 




je 


exit int 


;exit if buffer iB full 


mov 


f bx),al 


.•insert character in buffer 


mov 


buffer head, dx 


; advance head pointer 


mov 


al,20h 


; signal EOI to the 8259 


out 


INTA00,al 




sti 




; interrupts on 


pop 


ds 


; restore registers 


pop 


dx 




pop 


bx 




pop 


ax 




iret 




; return from interrupt 


endp 






ends 






end 


main 
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from the buffer, READ_CHAR temporar- 
ily clears interrupts and keeps them dis- 
abled during the critical time interval when 
it manipulates buffer pointers. 

NEXT UP: OS/2 

DOSTERM is about as uncomplicated as a 
functioning interrupt-driven serial com- 
munications program can be. Although it 
works, it's of limited practical use since it 
lacks the features we expect from commer- 
cial communications packages: the ability 
to adjust line settings on the fly, to dial 
phone numbers, to upload and download 
files, and more. What it does is to illustrate 
just how such programs are implemented 
under DOS. If you've never seen it done 



The DOSTERM 
program illustrates 
how functioning 
interrupt-driven 
serial 

communications 
programs are 
implemented under 
DOS. 



before, it may seem a daunting task even to 
try. Once you know how, you can see that 
a few cookbook routines are all that you 
need to get started. 

In the next Lab Notes, we'll take a look 
at the OS/2 communications environment 
and see how DOSTERM can be adapted to 
OS/2. You'll find that OS/2's support for 
serial I/O is much richer, making programs 
easier to write. Many common communi- 
cations functions are handled automati- 
cally, including input and output stream 
buffering, RS-232 handshaking, and 
XON/XOFF flow control. And since 
iandard OS/2 API functions are sufficient 
to access the driver, programs can be writ- 
ten in C as easily as in assembly language. 



Equivalent code listings are thus simpler, 
shorter, and more concise, which is one in- 
dication that the greater portion of the load 
is being carried by the operating system, 
not by the application program running on 
top of it. 

More importantly, the OS/2 COM driv- 
er works completely in the background 
and delivers all the functionality needed by 
commercial-quality programs. The mul- 
tithreaded programming techniques avail- 



able in OS/2 eliminate the code serializa- 
tion endemic to DOS applications. This 
shifts the burden of arbitrating between in- 
put requests generated at the UART level 
and output requests generated at the key- 
board — for example, from the application 
to the operating system. It's an exciting 
prospect for the next issue ! ■ 



JeffProsise is a contributing editor of PC 
Magazine. 



Here's the PC Voice Mail system that can 
increase your productivity by over 9 weeks. 



The average business person wastes 
5 to 7* hours each week on the tele- 
phone. That's over 9 weeks a year of 
wasted time and profits. That's why you 
need Watson. 

What Is Watson? 

It's the $199 hardware and software 
system that turns your PC and tele- 
phone into an intelligent communica- 
tions system that outperforms voice 
messaging systems costing thousands 
of dollars more. 

Why Watson? 

Because Watson invented the cate- 
gory of PC voice mail. Because PC 
Magazine selected Watson Version 1 
as "Editor's Choice for Product of the 
Year in 1984." Because Watson Version 
6.23 is a Hayes compatible modem 
(1200 or 2400 BPS) that runs com- 
pletely in the background without inter- 
fering with other computing functions. 
Because Watson comes with a 60- 
day free support program. Because 
Watson has over 30,000 satisfied 
users. And because over 45% of 
our sales come from user referrals! 

All This For Just $199. 

With basic Watson you'll get a single or 
multiple user system that answers the 
phone; forwards messages to any 
phone, even pagers; provides private 
and public voice mailboxes; gives you 
a personal calendar and programma- 
ble alarms plus a dictation system with 
full featured voice editing. You'll get 
auto dialing, remote access operation 
and message retrieval. Plus a sortable 
phone book based on a Rolodex™ 
file card structure in which you can 
enter free form notes and do key word 
searches. And it's all yours for just $199. 

"George Walther, Phone Power (New York: Berkley Books 



Watson-Voice Information 
System (VIS)" Option. 

An English-like command language 
that allows you to customize voice mes- 
sages, control message sequences 
with touch tones for both inbound and 
outbound response applications. 

Hear All About It. 

To decide which Watson is right for 
you, call our Demo Hotline. You'll hear 
an actual demonstration and discover 
all the ways Watson can work for you. 

Call Our Demo Hotline Now. 

1-800-6-WATSON, EXT. 243. In MA 

1-508-651-2186 EXT. 243. Or to order 
Watson directly, call 1-800-533-6120 
EXT. 243 (in MA 1-508-655-6066 
EXT. 243). 

MasterCard, VISA, and American 
Express accepted. 

30 Day Money-Back Guarantee. 

Try Watson for 30 
days. If you aren't 
completely satisfied, 
return it for a full 
refund. 

FREE Copy Of 
Phone Power 
Just For 
Listening 
To Our Demo. 
We'll send you a free 
copy of Phone Power, if you call 
before 10/31/89 and ask for extension 
243. No order necessary. Over 200 
pages of practical techniques for small 
business owners and company execu- 
tives. Make your telephone and your 
time more profitable. 



Call on the power of 





from Natural Microsystems 

k 8 Erie Drive, Natick. MA 01760-1313 
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